Date: Sat, 26 Mar 94 04:30:21 PST 

From: Ham-Space Mailing List and Newsgroup <ham-space@ucsd.edu> 
Errors-To: Ham-Space-Errors@UCSD.Edu 

Reply-To: Ham-Space@UCSD.Edu 

Precedence: Bulk 

Subject: Ham-Space Digest V94 #71 

To: Ham-Space 


Ham-Space Digest Sat, 26 Mar 94 Volume 94 : Issue 71 


Today's Topics: 
How to Talk to Mir? 
Navstar GPS Constellation Status (94-03-23): Correction 
On-line satellite schedules? 
Telecom and Meteors (2 msgs) 
what does NO -2 N4USH mean? 


Send Replies or notes for publication to: <Ham-Space@UCSD.Edu> 
Send subscription requests to: <Ham-Space-REQUEST@UCSD.Edu> 
Problems you can't solve otherwise to brian@ucsd.edu. 


Archives of past issues of the Ham-Space Digest are available 
(by FTP only) from UCSD.Edu in directory "mailarchives/ham-space". 


We trust that readers are intelligent enough to realize that all text 
herein consists of personal comments and does not represent the official 
policies or positions of any party. Your mileage may vary. So there. 


Date: Fri, 25 Mar 1994 21:56:35 GMT 

From: ihnp4.ucsd.edu!dog.ee.1lbl. gov! agate! boulder! cnsnews!spot.Colorado.EDU! 
millerpe@network.ucsd.edu 

Subject: How to Talk to Mir? 

To: ham-space@ucsd.edu 


I am a new ham and just beginning to read about satellite 

communications with ham radio. I have seen an article that 

explained that the Mir space station was fairly easy to communicate 

with. What is the minimum setup that might mbe necessary for me to attempt 

a contact - or even listen to the station. I have downloaded a few satellite 
tracking packages and if I am using them correctly I believe I know when 

it sould be overhead. The article also mentioned that 145.55 MHZ was the 
frequency to use. 


Any help or tips would be greatly appreciated. 


Peter Miller 


millerpe@spot.colorado.edu 


Peter M. Miller Home: 303-494-6990 
Computing and Network Services - Small Systems Work: 303-492-4866 
University of Colorado - Boulder millerpe@spot.colorado.edu 


Date: 25 Mar 1994 10:50:54 -0800 

From: dont-send-mail-to-path-lines@ames.arpa 

Subject: Navstar GPS Constellation Status (94-03-23): Correction 
To: ham-space@ucsd.edu 


The Navstar GPS Constellation Status table dated 94-03-23 contains an 
error in the notes section. Some of the details in note 8 actually 
refer to PRN13 not PRNO3. Both of these Block I satellites are 
currently set unhealthy. I have revised the table and notes 8 and 12 
now correctly reflect the situation. Thanks to Francine Vannicola of 
the U.S. Naval Observatory for pointing out the error. 


Navstar GPS Constellation Status 


(94-03-25) 

Blk NASA Orbit Launch 

II PRN Internat. Catalog Plane Date 

Seq SVN Code ID Number Pos'n (UT) Clock Available/Decommissioned 

Block I 
01 04 1978-020A 10684 78-02-22 78-03-29 85-07-17 
02 O07 1978-047A 10893 78-05-13 78-07-14 81-07-16 
03 06 1978-093A 11054 78-10-06 78-11-13 92-05-18 
04 08 1978-112A 11141 78-12-10 79-01-08 89-10-14 
05 05 1980-011A 11690 80-02-09 80-02-27 83-11-28 
06 09 1980-032A 11783 80-04-26 80-05-16 91-03-06 
07 81-12-18 Launch failure 
08 11 1983-072A 14189 83-07-14 83-08-10 93-05-04 


09 13 1984-059A 15039 C-1 84-06-13 Rb 84-07-19 
10 12 1984-097A 15271 A-1 84-09-08 Rb 84-10-03 
11 03 1985-093A 16129 C-4 85-10-09 Rb 85-10-30 


Block II 

II-1 14 14 1989-013A 19802 E-1 89-02-14 Cs 89-04-15 05:02 UT 
II-2 13 02 1989-044A 20061 B-3 89-06-10 Cs 89-08-10 20:46 UT 
II-3 16 16 1989-064A 20185 E-3 89-08-18 Cs 89-10-14 20:21 UT 
II-4 19 19 1989-085A 20302 A-4 89-10-21 Cs 89-11-23 03:13 UT 
II-5 17 17 1989-097A 20361 D-3 89-12-11 Cs 90-01-06 03:30 UT 


II-6 18 18 1990-008A 20452 
II-7 20 20 1990-025A 20533 
II-8 21 21 1990-068A 20724 
II-9 15 15 1990-088A 20830 


3 90-01-24 Cs 90-02-14 22:26 UT 
-2 90-03-26 Cs 90-04-18 23:13 UT 
2 90-08-02 Cs 90-08-22 15:00 UT 
2 90-10-01 Cs 90-10-15 00:39 UT 


Block IIA 

II-10 23 23 1990-103A 20959 
II-11 24 24 1991-047A 21552 
II-12 25 25 1992-009A 21890 
II-13 28 28 1992-019A 21930 
II-14 26 26 1992-039A 22014 
II-15 27 27 1992-058A 22108 
II-16 32 01 1992-079A 22231 
II-17 29 29 1992-089A 22275 
II-18 22 22 1993-007A 22446 
II-19 31 31 1993-017A 22581 
II-20 37 07 1993-032A 22657 
II-21 39 09 1993-042A 22700 
II-22 35 05 1993-054A 22779 
II-23 34 04 1993-068A 22877 


90-11-26 Cs 90-12-10 23:45 UT 
91-07-04 Rb 91-08-30 04:44 UT 
92-02-23 Cs 92-03-24 11:00 UT 
92-04-10 Cs 92-04-25 20:32 UT 
92-07-07 Cs 92-07-23 19:43 UT 
92-09-09 Cs 92-09-30 20:08 UT 
92-11-22 Cs 92-12-11 14:49 UT 
92-12-18 Cs 93-01-05 16:39 UT 
93-02-03 Cs 93-04-04 05:20 UT 
93-03-30 Cs 93-04-13 20:53 UT 
93-05-13 Cs 93-06-12 16:15 UT 
93-06-26 Cs 93-07-20 12:54 UT 
93-08-30 Cs 93-09-28 19:29 UT 
93-10-26 Cs 93-11-22 18:20 UT 
II-24 36 06 1994-016A 23027 94-03-10 Projected usable 94-04-18 

38 To be launched on need '94 

33 To be launched on need in FY '94 

40 To be launched on need in FY '95 

30 To be launched on need in FY '95 
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Notes 
1. NASA Catalog Number is also known as NORAD or U.S. Space Command object 
number. 


2. No orbital plane position = satellite no longer operational. 

Clock: Rb = Rubidium; Cs = Cesium 

4. S/A had been enabled on Block II satellites during part of 1990; S/A off 
between about 10 August 1990 and 1 July 1991 due to Gulf crisis; standard 
level re-implemented on 15 November 1991. Currently, PRN15 and PRN20 appear 
to have little or no S/A imposed. 

5. Anti-spoofing was activated on 94-01-31 at 0000 UT on all Block II 
satellites. (ref. NANU 0050-94042) 

6. PRN number of SVN32 was changed from 32 to 01 on 93-01-28. 

7. PRNO3 is operating on Rb clock without temperature control. 

8. PRNO3 was set unhealthy on 94-02-27 at 0320 UT. It was unusable beginning 
at 0233 UT on 94-02-27 and will remain unusable until further notice. (ref. 
NANU 083-94059) 

9. The decommissioning date for PRNOQ6/SVNO3 is the date of termination of 
operations of this satellite (ref. USNO) and is about 3 weeks later than the 
date GPSIC gives for "deactivation". 

10. The PRNO6/SVN36 launch included the SEDS-2 tether experiment on the Delta II 
rocket body (object 23028, 1994-016B). 


w 


11. PRNO9I was unusable beginning 93-10-15 1200 UT until 93-12-07 1940 UT due to 
testing. (ref. NANU 327-93288 and NANU 402-93341) 

12. PRN13 was set unhealthy on 94-02-27 at 1302 UT and will remain unusable 
until further notice due to "end of life testing." (ref. NANU 083-94059 and 
USNO). It is unlikely that PRN13 will return to service. (ref. USNO) 

13. The degraded C/A-code performance of PRN19 was corrected effective 94-01-04 
at 0000 UT. (ref. NANU 343-93294, NANU 396-93337, and NANU 006-94010) 

14. PRN24 was unusable from 94-01-23 1745 UT until 94-02-01 1516 UT due to a 
change in operational frequency standard from Cs to Rb. (ref. NANU 
023-94023, NANU 029-94024, NANU 9034-94032, and USNO) 


Richard B. Langley Internet: LANG@UNB.CA or SE@UNB.CA 
Geodetic Research Laboratory BITnet: LANG@UNB or SE@UNB 

Dept. of Geodesy and Geomatics Engineering Phone: (506) 453-5142 
University of New Brunswick FAX: (506) 453-4943 
Fredericton, N.B., Canada E3B 5A3 Telex: 014-46202 


Date: Fri, 25 Mar 94 07:05:37 GMT 

From: ihnp4.ucsd.edu!usc!howland.reston.ans.net!agate!msuinfo!netnews.upenn.edu! 
news.amherst.edu!nic.umass.edu!usenet@network.ucsd.edu 

Subject: On-line satellite schedules? 

To: ham-space@ucsd.edu 


Is there an on-line source of data about Oscar and RS satellite schedules 
of operation? 


Albert S. Woodhull 
Hampshire College, Amherst, MA, USA 
awoodhull@hamp. hampshire. edu 


Date: Fri, 25 Mar 94 07:02:29 GMT 

From: ihnp4.ucsd.edu!agate!msuinfo! netnews.upenn.edu!news.amherst.edu! 
nic.umass.edu!usenet@network.ucsd.edu 

Subject: Telecom and Meteors 

To: ham-space@ucsd.edu 


In Article <Cn6yLn.Mz0@ncifcrf.gov> mack@ncifcrf.gov (Joe Mack) writes: 


> [Communication via meteors has] never taken off and as far as I can tell it 
>'s only being used by experimenters. 


I believe I read a few years ago about meteor scatter being used by 


remotely located unmanned weather stations to relay information to 

central locations using packet radio techniques. The information is 
bundled into packets that are small enough and transmitted rapidly enough 
that an entire packet has a good chance of getting through in its 
entirety. The packet protocol verifies receipt of packets and causes 
retransmission of unverified packets until they are successfully received. 
Since the total volume of information is relatively small the overall data 
rate is satisfactory. 


My recollection is vague, but this could have been an article in the 
journal Science, and perhaps it was as long ago as the late '70s. I 
think I recall a color picture of a remote weather station in the arctic 
on the cover of the issue. I would be pleased if someone could find 

the reference and send it to me. 


I wonder if hams have done work on meteor scatter packet transmission? It 
would have to be done on clear channels and with very specialized 
parameters (short packets, unlimited retries, fast response). 


On a related topic, I have sometimes noticed when propagation is marginal 
but not entirely dead on 10 or 15 meters that weak signals will "pop up" 
briefly and then return to their normal level. I have suspected, but do 
not know for sure, that this is due to meteor trail reflections. 


Albert S. Woodhull N1AW 
Hampshire College, Amherst, MA, USA 
awoodhull@hamp. hampshire. edu 


Date: 25 Mar 1994 18:01:18 GMT 

From: ihnp4.ucsd.edu!dog.ee.1lbl.gov!agate!blanket.mitre.org!linus.mitre.org! 
wralston.mitre.org!user@network.ucsd.edu 

Subject: Telecom and Meteors 

To: ham-space@ucsd.edu 


In article <2mv5b9$t13@nic.umass.edu>, awoodhull@hamp.hampshire.edu wrote: 
In Article <Cn6yLn.Mz0@ncifcrf.gov> mack@ncifcrf.gov (Joe Mack) writes: 


> [Communication via meteors has] never taken off and as far as I can tell it 
>'s only being used by experimenters. 


I believe I read a few years ago about meteor scatter being used by 
remotely located unmanned weather stations to relay information to 
central locations using packet radio techniques. The information is 
bundled into packets that are small enough and transmitted rapidly enough 
that an entire packet has a good chance of getting through in its 
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entirety. The packet protocol verifies receipt of packets and causes 
retransmission of unverified packets until they are successfully received. 
Since the total volume of information is relatively small the overall data 
rate is satisfactory. 


VVNV NV 


There is a system call SNOTEL operating in the western US which collects 
information on snowpack levels operated by the US Dept of Agriculture. The 
equipment was built my Meteor Communications Corporation, Kent, WA. 


The ASAF used to operate a meteor-burst link in Alaska as a back up to a 
satellite link which was frequently disrupted by aurora. I think this 
system was dismantled. 


A number of meteor burst telemetry systems exist internationally for 
hydro-meteorological data collection. At one time there were systems 
operating in Egypt and in Uganda - I don't know of their current status. 


-- Bill wtr@mitre.org 
x I babble too incoherently to speak for my employer x 


Date: Fri, 25 Mar 1994 19:31:49 GMT 

From: mdisea!mothost!schbbs!news@uunet.uu.net 
Subject: what does NO -2 N4USH mean? 

To: ham-space@ucsd.edu 


In article <9403242326.AA24705@freenet3.scri.fsu.edu>, bmm1i@freenet2.scri.fsu.edu 
(Bruce M. Marshall) says: 

> 

>I am trying to establish an uplink to U022 and so far have all I have 

>gotten is the message 'NO -2 N4USH'. What does this mean? Does anyone 

>have any info on what all the information that OSCARS 22, 23 & 25 

>routinely downlink means? Some is obvious, some is not. I have found 

>some problems and corrected them and am waiting for evening passes to 

>check them out. Any suggestions or comments on debugging uplinks would 

>be appreciated. 

>thanks, Bruce. NA4USH 

Ske 

>Bruce M. Marshall bmmi@freenet.fsu.edu voice 615 481 0990 fax 615 481 8039 


It means that the file that you requested to be downloaded is no longer 
availabledownload by the 

file server. There is a parameter in the header of the file controlled by the 
uploader which 

specifies how long the file is to kept active in the directory. If its something 
you really need, 


upload a message to "ALL" asking for the original uploader or anyone else who 
might have it to 
upload it again. Hope this helps. 


73's 
Ned Stearns AA7A 
email: ned_stearns@email.mot.com 


End of Ham-Space Digest V94 #71 
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